In current wireless Access Networks (ANs), a wireless communication device sends a signaling message or data over an Access Channel (ACH) before the network grants the device access with a dedicated channel. The ACH is usually shared among wireless devices, and congestion may occur on the ACH if many devices attempt to access the network within a short period of time. In order to minimize congestion on the ACH, most wireless technologies utilize “Persistence Test with Backoff” mechanism referred to herein for simplicity as the “Persistence Test”.
When utilizing the Persistence Test, the wireless network usually defines a number of device classes. Each device class is assigned a persistence value, which is usually broadcast by the AN. Each device is configured to associate with a device class. When a device attempts to send data to the AN through the ACH, the device must perform and pass the Persistence Test before the device can send any data to the AN. The device generates a random persistence value and is considered to have passed the test when the random persistence value it generated is equal to or larger than the persistence value assigned to the device's associated class. If the test is not passed, the device waits for a “Backoff” time period and then performs another Persistence Test with a new random value. Thus, the test essentially acts as a throttle. Even though a large number of devices attempt to send data within a short period of time, this test can help to reduce potential ACH collisions and hence reduce the congestion.
The Persistence Test with Backoff mechanism works well most of the time in existing wireless networks such as Global System for Mobile Communications (GSM) and Code Division Multiple Access (CDMA) networks where most of the calls are voice-call related or are packet-data calls that require human intervention. However, wireless communications are changing, and Machine-to-Machine (M2M) communication is gaining traction. M2M communications involve communication (using wired or wireless means, or a combination of both) between two machines without human intervention. It is noted here that the term “M2M communication” is also referred to as “Machine Type Communication (MTC)” in certain literature. However, for the sake of consistency, only the term “M2M communication” is used in the discussion herein. Some examples of M2M communications are: smart metering (e.g., remote reading of a utility meter), healthcare monitoring (e.g., remote monitoring of a patient's heart rate), agricultural monitoring (e.g., monitoring of a crop condition), fleet management tracking (e.g., monitoring current status of trucks on road), security surveillance (e.g., automatic, real-time monitoring of a building or complex), billing transactions, inventory management (e.g., through monitoring of Point of Sale (POS) transactions in a supermarket) etc. These M2M communications typically use M2M communications-capable sensors or diagnostic devices (which may perform the metering, monitoring, etc., mentioned earlier) on one end and an M2M user device or receiver on the other end to receive data (e.g., wirelessly via a cellular Access Network as discussed below with reference to FIG. 1) from the sensor devices and process the data as per desired M2M service (e.g., utility metering service, healthcare monitoring service, billing preparation service, etc.).
With M2M communication and M2M-type devices introduced to the market, the number of wireless devices an access network needs to support has grown exponentially. There are many different types of M2M devices. Some are delay tolerant while some are time critical; some may only send data once a month while others send data more frequently; some may be fixed while others are mobile. In fact, unlike a legacy wireless device (i.e., a mobile phone including smart phone), there can be many different M2M device types, each with different characteristics and access requirements.
One of the potential M2M device types has the time/delay tolerance characteristic. For example, a utility meter with wireless access can be this type of M2M device. Depending on the application, there many such devices may be deployed within a small geographic area (e.g., gas meter, electricity meter). During normal operation, this type of device may only need to send data to the network once a day or less often. The service provider of these devices can also schedule the network access for these devices during off-peak hours so that normal wireless communication is not impacted.
During normal operation, the existing Persistence Test mechanism and the configured communication schedule enables the network to handle a large number of M2M devices and does not add much burden to the network (i.e. congestion issue). But the Persistence Test mechanism is still not enough to handle possible congestion under some external events such as recovery after a power outage. These external events may trigger a large number of M2M devices (for example, time tolerant devices such as utility meters) to reconnect with the network simultaneously. Even with the Persistence Test mechanism in place, there can be large number of devices trying to connect to the network through the ACH at the same time, which causes collisions and leads to RF-congestion. Large scale RF-congestion may also lead to core network congestion.